|
Field Association Integrations:
The Field Association import is a Kenexa Recruiter
BrassRing XML integration type that allows you to create field
associations and update or delete existing ones, as well as import new
parent field options. The client sends Kenexa Recruiter BrassRing an XML
request using the Field Association XML schema.
Field
association allows the selection of an option in a parent field to
determine the options that are available in one or more subsequent child
fields on a requisition form or Talent Gateway search page.
Depending on
how you configure the association between parent and child fields, you can
configure child fields to display any of the
following:
·
A full list of options
·
A full list of options with a default option
selected
·
A full list of options with multiple defaults
selected (for multi-select fields)
·
A subset of options
·
A subset of options with a default option
selected
·
A subset of options with multiple defaults selected
(for multi-select fields)
·
A single value
Field
association lets you build job postings based on selections made within
specific associated requisition fields, providing a more efficient
recruiter workflow and reducing errors. In Talent Gateways, field
association allows candidates who are searching for openings to pick from
a rich set of conditional list selections that are derived from the
requisition fields and logic implemented in Kenexa Recruiter BrassRing.
Candidates can select criteria from one search field and have subsequent
search fields restricted to options applicable only to the initial
criteria selections.
BrassRing
provides two mechanisms which can be used alone or together for importing
field associations and maintaining field association data:
1.
XML field association import and
2.
WorkBench field association import.
Note: For initial
seeding of data, it is recommended to follow the Workbench approach to
configure Field Associations.
Clients can encrypt the data in XML requests and responses
with AES encryption. If the client chooses to exchange data with Kenexa
Recruiter BrassRing via a web service, Kenexa can also configure security
policies at the integration type and subscription
level.
For
more details about Kenexa Recruiter AES implementation integrations, ask
your Kenexa representative for a copy Kenexa AES Encryption Application
Guide.doc
When
you send a field association import feed, Kenexa Recruiter BrassRing
returns a synchronous response that specifies whether or not the request
has been received. Because of the level of validation that needs to occur
for this type of import, Kenexa handles the actual processing of the
import through an off-line, asynchronous process. Once the off-line
process finishes importing field associations, Kenexa sends a message to
an email address or through acknowledgement via a URL that the client
specifies. More on acknowledgements in the next
section.
This
email message tells you whether or not the import was successful and prompts you to review the
import report in the WorkBench Task Manager. The report details the import
activity:
·
Lists records that were successfully
added
·
Lists records that were successfully
updated
·
Lists record updates or additions that failed and
supplies a reason for each failure.
For
descriptions of messages in the XML and email responses, see Error
conditions and Messages on page 18.
<Acknowledgement
type="httppost">https://hris.com/HttpListeningConnector.asp</Acknowledgement>
Follow
these steps to display and access the field association import
report:
1.
Log into Kenexa Recruiter BrassRing WorkBench and
select
Tools > Task
Manager.
2.
WorkBench displays the Task Queue
window.
Tasks can appear in the following
statuses:
·
Completed (Successfully
processed)
·
Pending (Waiting to be picked up for
processing)
·
Running (Currently being
processed)
·
Failed (Could not be successfully
processed)
3.
To see the report for a Completed or Failed task,
click the binoculars icon to download a report in Microsoft Excel Workbook
(.XSL) format.
Each
field association requires two field types: a parent field and one or more
child fields.
Parent
fields control the selections available in one or more subsequent child
fields in a requisition form. When a user selects an option in a parent
field, that selection can restrict the options available in any associated
child fields to a subset of the full list normally available in that
field. Additionally, an option selected in a parent field can cause child
fields to display default selections.
In the
following illustration, Location is the parent and Department is the
child. Each selection in the Location field causes a different subset of
departments to be available in the Department
field.
The selection made within the parent
field will determine which options appear in the child field.
|
A
parent field can have one or more child fields, but a child field can have
only one parent field. For example, Location can be the parent field for
Department and Division. However, if Location is the parent field to
Department, Location is the only field that can control the options
displayed in the Department field; the Division field cannot also control
the options displayed in Department. (Note that you could make this
association work by making Location the parent of Division, and Division
the parent of Department.)
Additionally, a child field cannot be the parent of a sibling
field – that is, it cannot be the parent of another field controlled by
its own parent. For example, if Country is the parent field which controls
the behavior of both the State and City child fields, a selection in the
State field will have no impact on the list of options available in the
City list. The correct way to build this association is to make Country
the parent only of State, and make State the parent of
City.
If the
parent field is a multi-select field and a user selects more than one
option in the parent, the child will be populated with a combination of
all options associated with all parent selections. For example, suppose
Country is the parent field
and City is the child field. When a user selects both
USA and UK in the Country field, the City list
displays only US and UK cities instead of all cities
for all countries.
Circular field associations are not supported. For example,
if Department is a parent to Location and Location is a parent to Business
Group, Business Group cannot be the parent to
Department.
Hidden
fields cannot effectively function as either parent or child fields in a
field association. If a parent field is hidden on a specific req template,
field associations have no effect on any of its child fields. That is,
hidden parent fields have no control over the options available in their
child fields.
Field
associations are valid for all languages for the parent and child
fields.
You
can add options to parent fields only in your default language for Kenexa
Recruiter BrassRing. Parent options must be translated in WorkBench, just
like any other requisition field option.
Child
fields with option lists automatically inherit the parent’s language
selection. If you do not translate a child option into a specific language
in WorkBench, that option does not appear when the filtered list is
displayed in that language.
The
status of an option in a child field does not impact field association.
Kenexa Recruiter BrassRing allows you to associate an inactive child-field
option with parent-field options. When an option is selected in the
parent, associated options do not appear in the child field if they are
inactive, but do appear once they are
activated.
If a
selected option in a parent field is changed, even if child is a
non-editable field, the child option list is also
changed.
When
new options are added to a parent field, field associations must be
configured for each new option; otherwise child fields will show ALL
options.
Parent
fields must contain list options. The following table shows which field
types can function as parent fields in a field association and which
cannot because they do not contain a list of
options.
|
Field
type |
Valid
Parent? |
Notes |
|
Radio |
Y |
|
|
Single-select |
Y |
|
|
Checkbox |
Y |
Children of this parent
cannot be numeric, text box, text area or email field types.
|
|
Multi-select |
Y |
Children of this parent
cannot be numeric, text box, text area or email field types.
|
|
Query-select |
Y |
When importing new parent
field options, the integration feed or import fails and an error
message is displayed.
|
|
Pull-from
list |
Y |
When importing new parent
field options, the integration feed or import fails and an error
message is
displayed. |
|
Date |
N |
|
|
Text |
N |
|
|
Text
area |
N |
|
|
Label |
N |
|
|
Grid |
N |
|
|
SSN |
N |
|
|
Email |
N |
|
|
Autofill |
N |
|
|
Numeric |
N |
|
The
following table shows which field types can function as child fields in a
field association and which cannot.
|
Field
Type |
Valid
Child? |
Notes |
|
Radio |
Y |
Supports
only one default selection |
|
Single-Select |
Y |
Supports
only one default selection |
|
Checkbox |
Y |
|
|
Multi-select |
Y |
|
|
Text
box |
Y |
Not
for checkbox or multi-select parents |
|
Text
area |
Y |
Not
for checkbox or multi-select parents |
|
Numeric |
Y |
Not
for checkbox or multi-select parents |
|
Email |
Y |
Not
for checkbox or multi-select parents |
|
Query-select |
Y |
|
|
Pull
from list |
Y |
|
|
Date |
N |
|
|
Label |
N |
|
|
Grid |
N |
|
|
SSN |
N |
|
|
Autofill |
N |
|
PLANNING THE FIELD
ASSOCIATIONS
This
section provides some guidelines for planning field associations. Before
you begin creating requisitions and forms that contain field associations,
take a few minutes to read this section. Implementing these practices will
streamline the creation of field associations and reduce errors when you
import them.
Whenever possible, place a parent field above all its child
fields on the form. If a child field appears above a parent field, users
might make selections in the child field before making a selection in its
parent field. When a selection is eventually made in the parent field, the
selection the user already made in the child field is lost and the user is
not notified of the change.
To
create a field association between country, state/province, and city
fields, create custom Country and State/Province fields for the form. This
is necessary because the options for the standard Kenexa Recruiter
BrassRing country and state/province fields cannot be edited.
Kenexa
Recruiter BrassRing provides the following options to restrict the list of
values available for users to select in a requisition
field:
·
List
filtering lets you control the options available within a single req
field. List filtering is applied at the req template and language level.
At the req template level, specify which field options will appear for end
users of the template. If a field is shared across multiple req templates,
you must apply list filtering on a per-template basis. You also apply list
filtering on a per-language basis. This allows you to specify a different
set of options on each template or in each supported language.
·
Option
filtering lets you create associations between req fields to allow one
field to drive which options/responses are displayed in subsequent fields
on the same form. Option filtering is configured at the req field level.
This means that the basic field associations created at the index level
are shared across all req templates.
A
single req can include both list filtering and option filtering, but
conflicts between the two can arise, causing options that should be
available to be filtered out of lists. Kenexa recommends that list
filtering and option filtering not be implemented within the same
requisition fields.
The
following example illustrates problems that can occur when you mix list
filtering and option filtering:
A
recruiter is creating a req form and wants to include a field called
Department. If the if the req is created with req template A, the
Department value list displays two options, PM and SE; if the req is
created with req template B, the Department value list displays three
options, SE, QE and TS.
The
Department field is also the child of another field called Division. When
the Division selection = Product, the default selection in the Department
field is automatically set to PM.
When
the recruiter creates a requisition with req template A requisition, the
Department field includes the PM value, so there would be no conflict if
the value of Division was Product. In req template B, however, the PM
value has been filtered out of the Department field and so the field
association between Division and Department is lost.
When
using field associations across multiple languages and specifying a
default value for a child field, it is important to remember to translate
the child option in all available languages. If a child option is not
available in a specific language, no default will be selected for the
child field when the req is displayed in that language.
This section
describes how to add field associations in WorkBench. For information
about how field associations affect Kenexa Recruiter BrassRing
performance, see Performance Notes on page 40.
This section
describes how to add field associations when you create requisitions in
WorkBench.
Note : Client
should discuss with their Technical Consultant before such making
configuration changes
1.
Log into Kenexa Recruiter BrassRing WorkBench and
select Tools > Forms > Req
Forms.
2.
Click the Define Standard Req Fields
button.
3.
Click the Edit field attributes icon for
the field you want to update.
4.
For Custom fields, click the Save and Continue
button.
5.
Under Enable association, select Parent or Child. For Date, Label, Grid, SSN
or Autofill fields, both Parent and Child options are dimmed. See
“ABOUT PARENT AND CHILD
FIELDS” on page
2 for more
information.
·
Parent: Selections made in the parent field control
the options presented in associated child fields. If field associations
have not been configured, child fields will continue to display
un-filtered lists of options. For Numeric, Text box, Text area, or Email fields, this option is
dimmed. See “Valid Field
Types for Parent Fields”
on page 2 for more
information.
·
Child: The options available in the child field are
controlled by a selection in its parent field.
6.
(Optional) To display this field’s parent or child
fields in a new window, click Show
parent or Show
child.
7.
(Optional) If you selected Child in step 5 and want this
field to automatically select any configured default options when an
associated option is selected in its parent field, select Display full list with default
selection.
Caution: Selecting this option can cause
unintended results on the form. Specifically, the ability for a child
field to display distinct filtered lists for each option in its parent
field will be lost.
If the field is
configured with both default and non-default selection-related field
association data, selecting this option erases all the non-default data.
For example, suppose fields on a req are configured so that when a Kenexa
Recruiter BrassRing user selects NorthEast Sales from the Department
single-select list, the Location single-select list is populated with the
choices Boston (default), New York, and Providence. Boston is the default
choice, so it automatically populates the Location field. However, if you
selected the Display full list
with default selection option in WorkBench, Boston is the only available option; New York and Providence do not
appear.
8.
When you finish editing the field attributes, click
Save.
Use
the Field Association XML schema to create XML requests that add, edit, or
remove field associations. Like all Kenexa Recruiter BrassRing XML
Integration schemas, the field association XML schema conforms to the
HR-XML Provisional Envelope schema. A single XML request can accommodate
multiple parent updates; you don’t have to submit a separate file per
parent field.
Field
Association Import requests can include multiple <Parent> nodes. Kenexa
Recruiter BrassRing processes the nodes in the XML request in a linear
“first-come, first-served” order. This means that if the message includes
a <ParentValue> node
to add a new association and also includes a subsequent <RemoveAssociation> node,
it is possible that the newly added association will be removed. For this reason, if you send an
import request that both adds and removes associations, Kenexa recommends
that you place <RemoveAssociation> nodes
ahead of any <ParentValue> nodes.
There
are several special characters that are either not allowed or not
recommended for use within XML transmissions within text nodes, even
within the CDATA section.
These characters are: < (less than), > (greater than), &
(ampersand), '(apostrophe) and "(quotation mark).
In
cases where these options appear within a text node within the XML, these
characters must be escaped in order for the import to work without error.
The
following sample shows incorrect data within a CDATA
section:
<Payload><![CDATA[
<?xml
version="1.0"?>
<Association_Data>
<languages>
</languages>
<Parent
fieldname="" type="">
<ParentValue>
<Code>
</Code>
<Description>Black
& Decker</Description>
<Status></Status>…..
The
following sample shows the properly escaped
data:
<?xml
version="1.0"?>
<Association_Data>
<languages>
</languages>
<Parent
fieldname="" type="">
<ParentValue>
<Code>
</Code>
<Description>Black
& Decker</Description>
<Status></Status>…..
The
following table describes how special characters should be escaped in XML.
Note that only the characters "<" and "&" are strictly illegal in
XML. Apostrophes, quotation marks and greater than signs are legal, but
Kenexa recommends replacing them with the corresponding escape sequences,
as well.
|
Special
Characters |
Escaped
Character |
|
<
(less than) |
< |
|
>
(greater than) |
> |
|
&
(ampersand) |
& |
|
'
(apostrophe) |
' |
|
"
(quotation mark) |
" |
Other
special characters that are not allowed in the Code values in Field
Associations are :
|
Other
Special Characters |
Denotion |
|
; |
semi
colon |
|
" |
double quotes/single
quotes |
|
! |
exclamation |
|
~ |
tilda |
|
@ |
apple |
|
# |
hash |
|
= |
equal
to |
|
+ |
add |
|
? |
question
mark |
|
, |
comma |
|
> <
|
greater than / less
than |
|
% |
percent |
|
| |
pipe |
|
[ ]
|
square
brackets |
|
{} |
curly
braces |
The
other special characters cannot be escaped in the XML and are prohibited
to be used in the Code values as per the Kenexa design. Special characters
such as above conflict with non-XML integrations and can be mistaken or
conflict with delimiters in other
integrations.
The
details of the field association are contained in the <Payload> node. The
comments in the schema that follows describe the elements in the <Payload> node used to add field
associations.
<Payload><![CDATA[
<?xml
version="1.0"?>
<Association_Data>
<languages/>
<!--
Languages specifies all the supported languages for the form. This node is
required only when the payload contains text-based child fields,
specified in
the <TextValue> node. The valid value is a comma-separated
list of ISO
letters, for example, “EN,FR,DE”-->
<Parent
fieldname=""
type="">
<!--
The fieldname attribute is the database field name for the parent field.
Valid values for
type are “Standard” or “Custom” -->
<ParentValue>
<!--
Adds an option in the parent field that controls options in child fields
specified in this node. Code, Description, and Status are all
required. -->
<Code/>
<!--
Code is the unique key for the parent field. This value will not be
visible in Kenexa Recruiter BrassRing or on Talent Gateways.
-->
<Description/>
<!--
Description is the description of the field that appears in Kenexa
Recruiter BrassRing and on Talent Gateways. -->
<Sort/>
<!--
Sort is the sort order for the newly imported option. If the parent field
has been configured to display options in alphabetical order,
Kenexa
Recruiter BrassRing stores this file but simply ignores
it.-->
<Status/>
<!--
Valid values for Status are “A” (active) or “I” (inactive)-->
<Child
fieldname=""
type="">
<!--
The fieldname attribute is the database field name for the child field.
Valid values for the type attribute are “Standard” or “Custom”
-->
<ChildValue>
<Option/>
<!--
The value for <Option> can be either the unique key for the field or
its description value.-->
<DefaultSelection/>
<!--
Default selection values are “Yes” or “No” If missing or blank, the
value is assumed to be “No” -->
<ImportAction/>
<!--
Valid values for the Import Action are “Update” when adding an
association and “Delete” when removing an association -->
</ChildValue>
</Child>
<Child
fieldname=""
type="">
<!--
The fieldname attribute is the database field name for the child field.
Valid values for the type attribute are “Standard” or “Custom”
-->
<ChildValue>
<TextValue
Language=""/>
<!--
The value for <Option> can be either the unique key for the field or
its description value.-->
<TextValue
language=""/>
<!--
The language attribute specifies the supported languages for this
field. The valid value is a comma-separated list of ISO letters,
for
example, “EN,FR,DE”-->
<ImportAction/>
<!--
Valid values for the Import Action are “Update” when adding an
association and “Delete” when removing an association -->
</ChildValue>
</Child>
</ParentValue>
</Parent>
</Association_Data>
]]></Payload>
This
section includes various sample XML requests for adding field
associations.
Recommended and suggested practice for
sending FA data:
1.
If you have multiple child updates to be performed,
the suggested way is to send all the child updates for the parent in a
single XML transmission instead of sending one child and one parent in a
transmission. Processing one transmission is faster and easier than
processing multiple transmissions especially when number of child updates
is in the thousands. Field association XMLs can also process multiple
parents of the same parent type and their children in a single
XML.
2.
Also, as a recommended practice, we advice not to
send more than 10000 child options in total in an single XML or
transmission.
The
following sample XML associates a parent field, Location, with three child
fields, Department, Business_Segment and
Manager.
<?xml
version="1.0"?>
<Association_Data>
<Parent
fieldname="Location"
type="Custom">
<ParentValue>
<Code>Boston</Code>
<!--
Note: the empty Child node below is for cleanup purposes - do not remove
-->
<Child
fieldname="" type="">
<ChildValue>
<ImportAction>Delete</ImportAction>
</ChildValue>
</Child>
<!--
End of cleanup section -->
<!--
Begin new associations -->
<Child
fieldname="Department"
type="Standard">
<ChildValue>
<Option>N14954</Option>
<DefaultSelection>Yes</DefaultSelection>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
<Child
fieldname="Business_Segment"
type="Custom">
<ChildValue>
<Option>8513</Option>
<DefaultSelection>Yes</DefaultSelection>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
<Child
fieldname="Manager" type="Standard">
<ChildValue>
<Option>43177923</Option>
<DefaultSelection>Yes</DefaultSelection>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
<!--
End new associations -->
</ParentValue>
</Parent>
</Association_Data>
<?xml
version="1.0"?>
<Envelope
version="01.00">
<Sender>
<!--
Do not modify this value -->
<Id>95JVXt4OlC7QuR5C45KKOw==</Id>
<!--
Do not modify this value -->
<Credential>P+5B94usOyFu2LrrlSKM3A==</Credential>
<!--
Email address where the async notification needs to go -->
<Email>someone@clientside.com</Email>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="data">
<TransactId>TRANSACTION
ID HERE</TransactId>
<TimeStamp>TIMESTAMP
HERE</TimeStamp>
</TransactInfo>
<Packet>
<PacketInfo
packetType="data">
<PacketId>1</PacketId>
<Action>SET</Action>
<!--
Do not modify this value -->
<Manifest>SmATto3FbaNs01J4r2BVZcZ4RcZTBuzCMU3TBof2vH8=</Manifest>
<PacketCode>IV
HERE</PacketCode>
</PacketInfo>
<Payload>
<EncryptedData
Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<CipherData>
<CipherValue>ENCRYPTED
CDATA SECTION HERE</CipherValue>
</CipherData>
</EncryptedData>
</Payload>
</Packet>
</Envelope>
<?xml
version="1.0"?>
<Envelope
version="01.00">
<Sender>
<Id>Kenexa
will provide</Id>
<Credential>Kenexa
will provide</Credential>
<Email>To
be determined by client</Email>
<remoteIP/>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="data">
<TransactId>1</TransactId>
<TimeStamp/>
</TransactInfo>
<Packet>
<PacketInfo
packetType="data">
<PacketId>1</PacketId>
<Action>SET</Action>
<Manifest>KWP_BUSINESSUNITSTD_FA</Manifest>
</PacketInfo>
<Payload><![CDATA[<?xml
version="1.0"
encoding="UTF8"?>
<Association_Data>
<Parent
fieldname="BUSINESS_UNIT_TI"
type="Custom">
<ParentValue>
<Code></Code>
<Child fieldname="STD_HOURS_TI"
type="Custom">
<ChildValue>
<TextValue Language="EN">
</TextValue>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
</ParentValue>
</Parent>
</Association_Data> ]]></Payload>
</Packet>
</Envelope>
New options can
be created only for parent fields if they don’t already exist. Child
options however cannot be created the same way and need to exist in the
system to be associated.
<?xml
version="1.0" encoding="UTF-8"?>
<Envelope
version="01.00">
<Sender>
<Id>Kenexa
will provide</Id>
<Credential>Kenexa
will provide</Credential>
<Email>someone@clientside.com</Email>
</Sender>
<Recipient>
<id/>
</Recipient>
<TransactInfo
transactType="data">
<transactId>123XYZ</transactId>
<timeStamp>2008-01-15</timeStamp>
</TransactInfo>
<Packet>
<PacketInfo
packetType="data">
<PacketId>1</PacketId>
<Action>SET</Action>
<Manifest>KWP_DEPID_REGION_FA</Manifest>
</PacketInfo>
<Payload><![CDATA[<?xml
version="1.0"?>
<Association_Data>
<languages>EN</languages>
<Parent
fieldname="Department"
type="Standard">
<ParentValue>
<Code>00002</Code>
<Description>00002 - 00002 - GLOBAL ONE
SALARIES</Description>
<Status>A</Status>
<Sort>1</Sort>
<Child fieldname="Region_GP_ELIG_GRP"
type="Custom">
<ChildValue>
<Option>10011</Option>
<ImportAction>Update</ImportAction>
<DefaultSelection>No</DefaultSelection>
</ChildValue>
</Child>
</ParentValue>
</Parent>
</Association_Data>
]]></Payload>
</Packet>
</Envelope>
<?xml
version="1.0"?>
<Envelope
version="01.00">
<Sender>
<Id>Kenexa
will provide</Id>
<Credential>Kenexa
will provide</Credential>
<Email>someone@clientside.com</Email>
<Acknowledgement
type="httppost">https://client.hris.com/HttpListeningConnector</Acknowledgement>
<remoteIP>125.247.13.19</remoteIP>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="data">
<TransactId>1668088|2007-12-12
17:33:57.720929</TransactId>
<TimeStamp>2007-12-12</TimeStamp>
</TransactInfo>
<Packet>
<PacketInfo
packetType="data">
<PacketId>1</PacketId>
<Action>SET</Action>
<Manifest>KWP_LOCATION_FA</Manifest>
</PacketInfo>
<Payload><![CDATA[<?xml
version="1.0"?> <Association_Data><Parent
fieldname="LOCATION_TWC"
type="Custom"><ParentValue><Code>DB04A –
WAYZATA</Code><Child
fieldname="Location/Division" type="Standard"><ChildValue><ImportAction>Delete</ImportAction></ChildValue></Child><Child
fieldname="Location/Division"
type="Standard"><ChildValue><Option>Minnesota - Minneapolis
- United
States</Option><ImportAction>Update</ImportAction><DefaultSelection>Yes</DefaultSelection></ChildValue></Child></ParentValue></Parent></Association_Data>]]></Payload>
</Packet>
</Envelope>
5.4.6 Example of grouping multiple
children for a parent field
The below example shows how to group each parent with its
children. In this example Location is the parent and has 2 children,
JobDescription and Department.
You can use this to group multiple children with its parent and is
a suggested method for sending large transactional
data.
<Envelope
version="01.00">
<Sender>
<Id>HRXMLUSER</Id>
<Credential>99999</Credential>
<Email>test@test.com</Email>
<Acknowledgement
type="httppost">https://hrms.test</Acknowledgement>
<remoteIP/>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="data">
<TransactId/>
<TimeStamp/>
</TransactInfo>
<Packet>
<PacketInfo
packetType="data">
<PacketId>1</PacketId>
<Action>SET</Action>
<Manifest>LOCATION_FA</Manifest>
</PacketInfo>
<Payload><![CDATA[<?xml
version="1.0"
encoding="UTF-8"?>
<Association_Data
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<languages>EN</languages>
<Parent
fieldname="LOCATION"
type="Custom">
<ParentValue>
<Code>L1</Code>
<Description>Location
1</Description>
<Sort>0</Sort>
<Status>A</Status>
<Child fieldname="JOBDESCRIPTION"
type="Custom">
<ChildValue>
<TextValue Language="EN">JOB
1</TextValue>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
<Child fieldname="Department"
type="Custom">
<ChildValue>
<Option>DEP
1</Option>
<DefaultSelection>Yes</DefaultSelection>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
</ParentValue>
<ParentValue>
<Code>L2</Code>
<Description>Location
2</Description>
<Sort>0</Sort>
<Status>A</Status>
<Child fieldname="JOBDESCRIPTION"
type="Custom">
<ChildValue>
<TextValue Language="EN">JOB
2</TextValue>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
<Child fieldname="Department"
type="Custom">
<ChildValue>
<Option>DEP
2</Option>
<DefaultSelection>Yes</DefaultSelection>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
</ParentValue>
<ParentValue>
<Code>L3</Code>
<Description>Location
3</Description>
<Sort>0</Sort>
<Status>A</Status>
<Child fieldname="JOBDESCRIPTION"
type="Custom">
<ChildValue>
<TextValue
Language="EN">JOB
3</TextValue>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
<Child fieldname="Department"
type="Custom">
<ChildValue>
<Option>DEP
3</Option>
<DefaultSelection>Yes</DefaultSelection>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
</ParentValue>
<ParentValue>
<Code>L4</Code>
<Description>Location
4</Description>
<Sort>0</Sort>
<Status>A</Status>
<Child fieldname="JOBDESCRIPTION"
type="Custom">
<ChildValue>
<TextValue Language="EN">JOB
4</TextValue>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
<Child fieldname="Department"
type="Custom">
<ChildValue>
<Option>DEP
4</Option>
<DefaultSelection>Yes</DefaultSelection>
<ImportAction>Update</ImportAction>
</ChildValue>
</Child>
</ParentValue>
</Parent>
</Association_Data>]]></Payload>
</Packet>
</Envelope>
This section describes the XML
requests that remove field associations.
In the
following schema, the <Child> element’s
fieldname and type attributes are left blank to indicate that associations
between the parent and all its children should be removed. This action
affects both text-based child fields and child fields
th
at
contain option lists.
<Parent>
<RemoveAssociation>
<Child
fieldname=""
type=""/>
</RemoveAssociation>
</Parent>
This
sample removes the associations between the ABC_DEPT (Department) field
and all its child fields. Once this import is processed, choosing an
option in the Department field has no effect on any other field in the
req.
<Parent
fieldname="ABC_DEPT"
type="Custom">
<RemoveAssociation>
<!--
<RemoveAssociation> completely removes the association between the
parent and child fields -->
<Child
fieldname=""
type=""/>
</RemoveAssociation>
</Parent>
In the
following example, the <Child> elements’
fieldname and type attributes are populated with values that specify which
child fields to disassociate with the parent. Associations between the
specified parent and any children not included in the XML request are
unaffected by this request.
<Parent
fieldname="ABC_DEPT"
type="Custom">
<RemoveAssociation>
<!--
<RemoveAssociation> completely removes the association between the
parent and
child
fields. -->
<Child
fieldname="FieldA"
type="standard"/>
<Child
fieldname="FieldC"
type="custom"/>
</RemoveAssociation>
</Parent>
In
this example, suppose the ABC_DEPT (Department) field has a third child
field, FieldB, which is not included in the request. After the import has
been successfully processed, selections made in the Department field no
longer affect FieldA or FieldC, but still control the options displayed
for FieldB.
In the
following example, the <Child> element’s
fieldname and type attributes are left blank to indicate that associations
between the parent and all its children should be removed. This action
affects both text-based child fields and child fields that contain option
lists. The <Option>
node is not required for this example because all associated child options
are removed.
<Parent
fieldname="ABC_DEPT"
type="Custom">
<ParentValue>
<Code>ENG2</Code>
<Child
fieldname=""
type="">
<ChildValue>
<ImportAction>Delete</ImportAction>
</ChildValue>
</Child>
</ParentValue>
</Parent>
In the
following example, the <Child> element’s
fieldname and type attributes are populated with values that specify which
child fields to disassociate with the parent option. Associations between
the specified parent option and any children not included in the XML
request are unaffected by this request. This action affects both
text-based child fields and child fields that contain option lists. The
<Option> node is not
required for this example because all associated child options are
removed.
<Parent
fieldname="ABC_DEPT"
type="Custom">
<ParentValue>
<Code>ENG2</Code>
<Child
fieldname="FieldA"
type="standard">
<ChildValue>
<ImportAction>Delete</ImportAction>
</ChildValue>
</Child>
</ParentValue>
</Parent>
In
this example, suppose the ABC_DEPT (Department) field has another child
field, FieldB, which is not included in the request. After the import has
been successfully processed, selections made in the Department field no
longer affect FieldA, but still control the options displayed for FieldB.
In the
following example, the <Child> element’s
fieldname and type attributes are populated with values that specify which
child fields to disassociate with the parent option. The <Option> node specifies
which child options to disassociate.
Associations between the specified parent option and any
child options not included in the XML request are unaffected by this
request. This action affects only child fields that contain option
lists.
<Parent
fieldname="ABC_DEPT"
type="Custom">
<ParentValue>
<Code>ENG2</Code>
<Child
fieldname="FieldA"
type="standard">
<ChildValue>
<Option>OptionB</Option>
<ImportAction>Delete</ImportAction>
</ChildValue>
</Child>
</ParentValue>
</Parent>
In
this example, suppose the parent field is Department (ABC_DEPT), the
parent option is Engineering (ENG2), the child field is Location (FieldA),
and the child field option is Boston (OptionB).
After
the import has been successfully processed, when a user selects the
Engineering option in the Department field, the Location field no longer
includes the Boston option, because the association
has been removed.
Real-time (synchronous) XML responses must be sent for all
inbound and outbound transactions.
For
all inbound transactions (imports), Kenexa Recruiter BrassRing provides a
synchronous XML response within the same transaction. If the response XML
contains CDATA sections in the payload, the <Payload> node is
encrypted to protect sensitive information.
It is
the client’s responsibility to log the XML responses and re-attempt the
transmission if the initial request was not successful. For more
information, see “Analyzing Failed Requests” on page 2.
Additionally, for Field Associations Imports, Kenexa
processes the message offline and sends asynchronous responses to an
e-mail address or URL that the client specifies. See “Asynchronous Error
Conditions and Messages” on page 2
for more information.
If an
error is detected during validation of an integration XML request, the
entire message is rejected and a failure response is returned
synchronously. Information in a failure response’s <Status> node
helps diagnose problems.
The
following elements are children of the <Status>
element:
·
The <Code> element contains the HTTP status
code associated with the outcome of the request. See “HTTP Status Codes”
on page 2 for more
information.
·
The <ShortDescription> element contains a
string that briefly describes why the request
failed.
·
The <LongDescription> element contains a string
that describes in detail why the request
failed
.
All
synchronous responses sent by Kenexa Recruiter BrassRing in an XML
integration – both success responses and failure responses – include one
of the following HTTP status codes:
|
HTTP Status
Code |
Description |
|
200 |
The request sent by the client was
successful. |
|
401 |
Access was denied because of a security or
authentication problem. This type of error might occur while Kenexa
and the client are setting up the integration in a test
environment. |
|
405 |
All failures related to anything other than security
and authentication. When the <Code> for a failure response is
405, check the detailed error message in <LongDescription> to
see if the error is the result of:
·
A permanent
condition that must be fixed before the request can be resubmitted.
For example, the request did not include the authenticated user’s
email address.
·
A transient
condition for which retrying the request is appropriate. For
example, there was a system problem like a database
timeout. |
These codes are generated when acknowledgement responses are
sent to the client if acknowledgement is
configured.
|
Ack
Codes |
Description |
|
1 |
Pending
|
|
2 |
Running |
|
3 |
Completed |
|
4 |
Failed
|
|
5 |
Suspended |
|
6 |
Unimplemented |
|
7 |
Launching |
|
8 |
Completed
with errors |
If a
request fails with a 405 status code and the error is not permanent, the
client should retry the request until it is
successful.
Retry
failed requests at intervals set using exponential back-off, an
algorithm that specifies that successive retransmission intervals should
increase exponentially, based on the initial (base) retransmission
interval.
The
following example describes the logic a client might develop to resubmit
failed requests.
// static
settings
Set max
retries = 15
Set initial
retry interval = 1 minute
Set max retry
interval = 60 minutes
Set notify
after retries = 6
//Notify that
the integration is delayed after six retry
attempts
// logic for
processing each request
Set retries
left = max retries
Set retry
delay = initial retry delay
Submit
request
Get Kenexa
synchronous response.
Was the
request successful?
//Response
contains HTTP status code 200
If Yes,
exit.
Did the
request fail because of a security/authentication
error?
//Response
contains HTTP status code 401
If Yes, notify and
exit.
Did the
request fail because of a data error?
//Response
contains HTTP status code 405
If No, notify (unrecognized error
code) and exit
Does error
description match fatal error pattern?
If Yes, notify (integration data
error) and exit
Is retries
left = 0?
If Yes, notify (too many retries)
and exit
Is max
retries - retries left = notify after
retries?
If Yes, notify and continue
Decrement
retries left
Sleep for
retry delay
Double retry
delay
Is retry
delay greater than max retry delay?
If Yes, set retry delay = max
retry delay
Go to "Submit
request"
This
section describes error responses you could see immediately upon
submitting the field association import request. These responses conform
to the HR-XML Provisional Envelope schema and apply to all Kenexa
Recruiter BrassRing secure integrations, not just to Field Association
Imports.
<Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="">
<Sender>
<Id>ZSARUZ/aATd7ct4LP4BM4Q==</Id>
<Credential>1sU9JELZ8z9tPsHw8FDjyw==</Credential>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId>TESTTRAN001</TransactId>
<TimeStamp>2006-09-26T11:00:14.000000-0400</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>Error
decrypting credentials</ShortDescription>
<LongDescription>Unable
to locate clientID</LongDescription>
</Status>
</TransactInfo>
</Envelope>
<Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="01.00"
xmlns="">
<Sender>
<Id>ZSARUZ/aATd7ct4LP4BM4Q==</Id>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId>TESTTRAN001</TransactId>
<TimeStamp>2006-09-26T11:00:14.000000-0400</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>Error
decrypting credentials</ShortDescription>
<LongDescription>Value
cannot be null.Parameter name: InString</LongDescription>
</Status>
</TransactInfo>
</Envelope>
<Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="">
<Sender/>
<Recipient/>
<TransactInfo
transactType="response">
<Status>
<Code>405</Code>
<ShortDescription>XML
Error</ShortDescription>
<LongDescription>Unable
to load xml passed in</LongDescription>
</Status>
</TransactInfo>
<Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="01.00"
xmlns="">
<Sender>
<Id>SARUZ/aATd7ct4LP4BM4Q==</Id>
<Credential>1sU9JELZ8z9tPsHw8FDjyw==</Credential>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId>TESTTRAN001</TransactId>
<TimeStamp>2006-09-26T11:00:14.000000-0400</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>Decrypt
failed</ShortDescription>
<LongDescription>Error
decrypting payload message</LongDescription>
</Status>
</TransactInfo>
</Envelope>
<Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="01.00"
xmlns="">
<Sender>
<Id>ZSARUZ/aATd7ct4LP4BM4Q==</Id>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId>TESTTRAN001</TransactId>
<TimeStamp>2006-09-26T11:00:14.000000-0400</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>Error
decrypting credentials</ShortDescription>
<LongDescription>Value
cannot be null.
Parameter
name: InString</LongDescription>
</Status>
</TransactInfo>
</Envelope>
<Envelope
xmlns:br="http://trm.brassring.com/integrations"
version="01.00"
xmlns="">
<Sender>
<Id>ZSARUZ/aATd7ct4LP4BM4Q==</Id>
<Credential>1sU9JELZ8z9tPsHw8FDjyw==</Credential>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId>TESTTRAN001</TransactId>
<TimeStamp>2006-09-26T11:00:14.000000-0400</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>Failure</ShortDescription>
<LongDescription>Data
transfer was not successful</LongDescription>
</Status>
</TransactInfo>
<Packet>
<PacketInfo
packetType="response">
<PacketId>1</PacketId>
<Action>SET</Action>
<Manifest>kW4v9E7x3a+ZcfPbfdjT2Q==</Manifest>
<Status>
<Code>405</Code>
<ShortDescription>Failure</ShortDescription>
<LongDescription>error
message raised from business layer</LongDescription>
</Status>
</PacketInfo>
</Packet>
</Envelope>
<Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="01.00"
xmlns="">
<Sender>
<Id>123</Id>
<Credential>1sU9JELZ8z9tPsHw8FDjyw==</Credential>
</Sender>
<Recipient>
<Id>https://integration1.brassring.com/Outbound/Outbound.asmx/ExternalPost</Id>
</Recipient>
<TransactInfo
transactType="response">
<TransactId>HSCAND12562</TransactId>
<TimeStamp>08/28/2006
10:01:00 AM</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>Communication
error</ShortDescription>
<LongDescription>Communication
error with business logic components (general)</LongDescription>
</Status>
</TransactInfo>
</Envelope>
This
response might be sent due to either hardware problems or network
configuration issues.
<Envelope
version="01.00"
xmlns="">
<Sender>
<Id/>
<Credential/>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId/>
<TimeStamp>10/4/2006
4:24:03 PM</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>System
Error</ShortDescription>
<LongDescription>Unable
to process the request. Please contact BrassRing.</LongDescription>
</Status>
</TransactInfo>
</Envelope>
<Envelope
version="01.00"
xmlns="">
<Sender>
<Id/>
<Credential/>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId/>
<TimeStamp>10/4/2006
4:24:03 PM</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>XML
Error</ShortDescription>
<LongDescription>Unable
to deserialize xml passed in</LongDescription>
</Status>
</TransactInfo>
</Envelope>
Remember that XML Field Association Imports can be encrypted
only with AES encryption.
<Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="01.00"
xmlns="">
<Sender>
<Id>ZSARUZ/aATd7ct4LP4BM4Q==</Id>
<Credential>1sU9JELZ8z9tPsHw8FDjyw==</Credential>
</Sender>
<Recipient>
<Id/>
</Recipient>
<TransactInfo
transactType="response">
<TransactId>TESTTRAN001</TransactId>
<TimeStamp>2006-09-26T11:00:14.000000-0400</TimeStamp>
<Status>
<Code>405</Code>
<ShortDescription>No
encryption type found</ShortDescription>
<LongDescription>Encryption
type undefined - NONE</LongDescription>
</Status>
</TransactInfo>
</Envelope>
This
section describes the messages Kenexa Recruiter BrassRing sends via email
and displays in WorkBench reports when asynchronous processing of the
import is complete. The first part of this section describes errors
contained in email messages and shows several sample email messages. The
second part describes each individual error message you might see in the
.XSL report you download from WorkBench. For details about downloading
this report, see “Displaying the Import Report in WorkBench” on page 2.
The
Task Name, which is displayed in the response email and in the WorkBench
Task List is a combination of the Manifest Name and the Task ID, displayed
as:
Manifest Name [Task ID: xxx]
5.4.1.1
Completed without
errors
|
From: BrassRing TaskManager
[mailto:TaskManager@brassring.com]
Sent: Friday,
September 22, 2006 4:51 PM
To: Robert P.
Foley
Subject: import task has completed
successfully
|
Task
Name: |
MY MANIFEST NAME [Task ID: My
Task ID] |
|
Environment: |
QA3 |
|
Client
Name: |
Novartis Pharma
AG |
|
Submitted
On: |
Friday, September 22, 2006
4:50:40 PM |
|
Started
On: |
Friday, September 22, 2006
4:50:43 PM |
|
Finished
On: |
Friday, September 22, 2006
4:50:44 PM |
|
Total Rows
Processed: |
2 |
|
Updates: |
2 |
Use Task Manager to view the
results.
This message was
e-mailed from a send-only account. Please do not reply. If problems
persist, please contact your assigned BrassRing support
representative. |
5.4.1.2
Import Failed (error in email
body)
|
From: Brassring Task Manager
[mailto:TaskManager@brassring.com]
Sent: Friday,
September 22, 2006 4:23 PM
To: Robert P.
Foley
Subject: import task has
failed
Importance: High
|
Task
Name: |
MY MANIFEST NAME [Task ID: My
Task ID] |
|
Environment: |
QA3 |
|
Client
Name: |
Novartis Pharma
AG |
|
Submitted
On: |
Friday, September 22, 2006
4:22:58 PM |
|
Error
Message: |
FR is not a client
language |
This message
was e-mailed from a send-only account. Please do not reply. If
problems persist, please contact your assigned BrassRing support
representative. |
5.4.1.3
Import Failed (error in email
body)
|
From: Brassring Task Manager
[mailto:TaskManager@brassring.com]
Sent: Thursday,
September 21, 2006 2:56 PM
To: Robert P.
Foley
Subject: import task has
failed
Importance: High
|
Task
Name: |
MY MANIFEST
NAME |
|
Environment: |
QA3 |
|
Client
Name: |
Novartis Pharma
AG |
|
Submitted
On: |
Thursday, September 21, 2006
2:56:00 PM |
|
Error
Message: |
Parent question name is not
specified. |
This message was
e-mailed from a send-only account. Please do not reply. If problems
persist, please contact your assigned BrassRing support
representative. |
5.4.1.4
Completed with errors (errors in WorkBench
report)
|
From: BrassRing TaskManager
[mailto:TaskManager@brassring.com]
Sent: Friday,
September 22, 2006 9:02 AM
To: Robert P.
Foley
Subject: import task has completed with
errors
|
Task
Name: |
Users [Task ID: My Task
ID] |
|
Environment: |
Dev3 |
|
Client
Name: |
ATest |
|
Submitted
On: |
Friday, September 22, 2006
9:01:31 AM |
|
Started
On: |
Friday, September 22, 2006
9:01:31 AM |
|
Finished
On: |
Friday, September 22, 2006
9:01:41 AM |
|
Total Rows
Processed: |
1 |
|
Errors: |
1 |
Use Task Manager to view the
results.
This message
was e-mailed from a send-only account. Please do not reply. If
problems persist, please contact your assigned BrassRing support
representative. |
In
addition to the messages displayed in the sample email messages that
follow, other custom messages included in email messages are provided from
Kenexa. These email messages all contain the subject line IMPORT TASK HAS
FAILED and are sent to an email address that the client provided to
Kenexa.
5.4.2.1
Can't find association
data
The
XML document does not contain a <Payload>
node.
5.4.2.2
Invalid internal XML in
'Association_Data'
The
text inside the [[CData]] section in the XML file is not properly
formatted XML.
5.4.2.3
ClientID is not
provided
The
XML document does not contain a <Credential>
node.
5.4.2.4
ClientID doesn't match
The ID
provided in the <Credential> node does not match the current client
ID.
5.4.2.5
Email address is not
provided
The
XML document does not contain an <Email>
node.
5.4.2.6
Parent question is not
specified
The
XML document does not contain a <Parent> node inside the
<Association_Data> node.
5.4.2.7
<language ISO letter> is not a client
language
The
value specified by the <languages> node inside the
<Association_Data> node either is not the correct client language or
is simply incorrect.
5.4.2.8
Parent question name is not
specified
The
<Parent> node does not contain a valid fieldname
attribute.
5.4.2.9
Parent question type is not
specified
The
<Parent> node does not contain a valid type
attribute.
5.4.2.10
Child question cannot have option and text value in
the same time
The
XML document includes a <ChildValue> node that contains both
<Option> and <TextValue> nodes. A <ChildValue> node can
contain only one or the other.
5.4.2.11
Child question must contain either text value or
option
The
XML document includes a <ChildValue> node that does not contain
either an <Option> or <TextValue> node. One or the other is
required for each <ChildValue> node.
The
following sections describe errors that might appear in the WorkBench
report you can download when an import is
complete.
5.4.3.1
Subscription name
required
When
creating an XML field association import subscription and Save as inactive
or Save as active is clicked, if a subscription name is not provided,
return the following error message: “You must enter a value for
“Subscription name””
5.4.3.2
Unique Subscription
name
When
creating an XML field association import subscription and Save as inactive
or Save as active is clicked, if a subscription name is not unique across
all subscriptions for that client, return the following error message:
“The name [insert name] is being used. Please enter different subscription
name.“
5.4.3.3
Manifest name required
When
creating an XML field association import subscription and Save as inactive
or Save as active is clicked, if a manifest name is not provided, return
the following error message: “You must enter a value for “Manifest
name””
5.4.3.4
Unique Manifest name
When
creating an XML field association import subscription and Save as inactive
or Save as active is clicked, if a manifest name is not unique across all
subscriptions for that client, return the following error message: “The
name [insert name] is being used. Please enter different manifest
name.“
5.4.3.5
Vendor/Host required
When
creating an XML field association import subscription and Save as active
is clicked (or if the Activate option is taken on the Subscription Admin
screen), if a vendor or host has not been selected, return the following
error message: “Please select a vendor or
host”
5.4.3.6
Key group required
When
creating an XML field association import subscription and Save as inactive
or Save as inactive is clicked, if either the Cypher or XML encrypt option
has been selected and a key group is not selected, return the following
error message: “A Key group must be
selected.”
5.4.3.7
Encrypt option required
When
creating an XML field association import subscription and Save as inactive
or Save as inactive is clicked, if either the Cypher or XML encrypt option
has been selected and at least one (1) encrypt option has not been
selected, return the following error message: “At least one (1) “Encrypt”
option must be selected.”
5.4.3.8
<ID> required
When
importing field associations via XML, if a value has not been passed in
the <ID> node, the following error message should be returned: “ID’ is
required.”
5.4.3.9
<ID> Invalid
When
importing field associations via XML, if the value passed in the
<ID> node is not a valid client ID, the following error message
should be returned: “ID’ is
invalid.”
5.4.3.10
<Credential>
required
When
importing field associations via XML, if a value has not been passed in
the <Credential> node, the following error message should be
returned: “Credential’ is
required.”
5.4.3.11
<Credential>
Invalid
When
importing field associations via XML, if the value passed in the
<Credential> node is not a valid userID, the following error message
should be returned:
“Credential’ is invalid.”
5.4.3.12
<Manifest>
required
When
importing field associations via XML, if a value has not been passed in
the <Manifest> node, the following error message should be
returned: “Manifest’ is
required.”
5.4.3.13
<Email> required
When
<Email> is configured, Field Associations notifications are sent to
the email address for information regarding success and
failures.
5.4.3.14
<Acknowledgement
>
optional
When
Acknowledgement is configured a detailed response is sent to the client
than the email address response. The Acknowledgement is a URL provided by
the client.
5.4.3.15
<Manifest>
Invalid
When
importing field associations via XML, if the value passed in the
<Manifest> node is not a valid manifest name for the client, the
following error message should be returned: “Manifest’ is
invalid.”
5.4.3.16
<Code> required
When
importing field associations via XML, if a value has not been passed in
the <Code> node, the following error message should be
returned: “Code’ is
required.”
5.4.3.17
<Description>
required
When
importing field associations via XML, if a value has not been passed in
the <Description> node, the following error message should be
returned: “Description’ is
required.”
5.4.3.18
<Status> required
When
importing field associations via XML, if a value has not been passed in
the <Status> node, the following error message should be
returned: “Status’ is
required.”
5.4.3.19
<Status> invalid
When
importing field associations via XML, if the value passed in the
<Status> node does not = “Active” or “Inactive”, the following error
message should be returned:
“Status’ is invalid.”
5.4.3.20
<DefaultSelection>
invalid
When
importing field associations via XML, if the value passed in the
<DefaultSelection> node does not = “Yes” or “No”, the following
error message should be returned:
“DefaultSelection’ is invalid.”
5.4.3.21
<ImportAction>
invalid
When
importing field associations via XML, if the value passed in the
<ImportAction> node does not = “Update” or “Delete”, the following
error message should be returned:
“ImportAction’ is invalid.”
5.4.3.22
Client name required
During
the import of field associations via Excel, if the client name is not
provided on the Properties tab, the following error message should be
returned: “’Client’ value
must be provided on ‘Properties’ tab.”
5.4.3.23
ParentQuestion required
During
the import of field associations via Excel, if a ParentQuestion value is
not provided on the Properties tab, the following error message should be
returned: “’ParentQuestion’
value must be provided on ‘Properties’ tab.”
5.4.3.24
IMPORT_ACTION required
During
the import of field associations via Excel, if a IMPORT_ACTION value is
not provided, the following error message should be returned: “’IMPORT_ACTION’ value must be
provided.”
5.4.3.25
IMPORT_ACTION invalid
During
the import of field associations, if a IMPORT_ACTION value does not = “Update” or “Delete”, the
following error message should be returned: “’IMPORT_ACTION’ is
invalid.”
5.4.3.26
ParentType required
During
the import of field associations via Excel, if a ParentType value is not
provided on the Properties tab, the following error message should be
returned: “’ParentType’ value
must be provided on ‘Properties’ tab.”
5.4.3.27
ParentType invalid
During
the import of field associations, if a ParentType value does not = “Standard” or “Custom”, the
following error message should be returned: “’ParentType’ is
invalid.”
5.4.3.28
ParentOption required
During
the import of field associations via Excel, if a ParentOption value does
not exist for a data row, the following error message should be
returned: “’ParentOption’
must be provided for each row of data on ‘Codes’
tab.”
5.4.3.29
ParentOption exceeds max
length
During
the import of field associations via Excel, if a ParentOption value
exceeds 50 characters, the following error message should be
returned: “[Column name]
cannot be more than [] characters long.”
5.4.3.30
ParentOptionDesc exceeds max
length
During
the import of field associations via Excel, if a ParentOptionDesc value
exceeds 255 characters, the following error message should be
returned: “[Column name]
cannot be more than [] characters long.”
5.4.3.31
ParentOptionSort exceeds max
length
During
the import of field associations via Excel, if a ParentOptionSort value
exceeds 5 characters, the following error message should be returned: “[Column name] cannot be more than
[] characters long.”
5.4.3.32
Status invalid
When
importing field associations via Excel, if the value passed in the
<Status> node does not = “Active” or “Inactive”, the following error
message should be returned:
“Status’ is invalid.”
5.4.3.33
ChildQuestion invalid
During
the import of field associations, if the value sent for a ChildQuestion
cell does not currently exist in Enterprise, the following error message
should be returned: “’Child
Question’ is invalid.”
5.4.3.34
ChildQuestion required
During
the import of field associations via Excel, if a ChildQuestion value does
not exist for a data row, the following error message should be
returned: “Child question’ is
a required field.”
5.4.3.35
ChildQuestion exceeds max
length
During
the import of field associations via Excel, if a ChildQuestion value
exceeds 30 characters, the following error message should be
returned: “’ “[Column name]
cannot be more than [] characters long.”
5.4.3.36
ChildType required
During
the import of field associations via Excel, if a ChildType value is not
provided for a data row, the following error message should be
returned: “’ChildType’ is a
required field.”
5.4.3.37
ChildType invalid
During
the import of field associations via Excel, if a ChildType value does not
= “Standard” or “Custom”, the following error message should be
returned: “’ChildType’ is
invalid.”
5.4.3.38
ChildOption required
During
the import of field associations, a value must be sent for the ChildOption
field if the ChildQuestion is not a text-based field. The only exception
to this is when the delete action is taken. If a value is not sent for a
ChildOption cell, the following error message should be returned: “Child option can be empty only
for Delete action.”
5.4.3.39
ChildOption invalid
During
the import of field associations, if the value sent for a ChildOption cell
does not currently exist in Enterprise for the child field, the following
error message should be returned:
“’ChildOption’ is not a valid value.”
5.4.3.40
ChildOption not allowed
During
the import of field associations, if a value sent for a ChildOption cell
for a field which does not support options (text field) , the following
error message should be returned:
“[Child field name] does not support options. ’ChildOption’ must be
removed.”
5.4.3.41
ChildOption exceeds max
length
During
the import of field associations via Excel, if a ChildOption value exceeds
255 characters, the following error message should be returned: “[Column name] cannot be more than
[] characters long.”
5.4.3.42
DefaultSelection
invalid
During
the import of field associations via Excel, if a DefaultSelection value
does not = “Yes” or “No”, the following error message should be
returned: “’DefaultSelection’
is invalid.”
5.4.3.43
ChildText exceeds max
length
During
the import of field associations via Excel, if a Child Text (language)
value exceeds 4000 characters, the following error message should be
returned: “[Column name]
cannot be more than [] characters long.”
5.4.3.44
Parent option may not be
added
During
the import of field associations, if the parent field is either a
query-select or pull from type field, new options may not be added to the
field through the field association import. The following error message should
be returned: “Insert is not allowed.”
5.4.3.45
Multi-select may not be parent to text-based
child
During
field association import, If the parent field is a multi-select or
checkbox type and a child field is a numeric, text box, text area or email
type field, the following error message should be returned: “[Field name]
is a multi-select field.
Multi-select field types may not be parents to fields which do not
contain option list.”
5.4.3.46
Invalid child field
type
During
the import of field associations, if the child field is not of a valid
field type to be a child field (Date, Label, Grid, SSN and Autofill) or if
the child field is the standard “Job code”, “Approval routing” or “Add
type” requisition fields, the following error message should be returned:
“[Field name] may not be used as a child
field.”
5.4.3.47
Invalid default option
During
the import of field associations, if the child field is a single-select or
radio button field type, and more than one (1) default selection is
specified for a specific parent, return the following error message:
“Multiple default selections are not allowed for single-select [or radio]
question.” (The error text
should be updated based on the child field
type.)
5.4.3.48
Multiple parents
During
the import of field associations, if a field has been previously
designated as a child of one field, and it is now being designated as a
child of a second field, return the following error message: “Child field
is already associated to another req field [field name]. A child field
cannot have more than one (1) parent.”
5.4.3.49
Circular relationships
During
the import of field associations, if Field A is a parent to Field B, Field
B is a parent to Field C, and a field association is imported where Field
C is a parent to Field A, return the following error message: “Circular
field relationships cannot be supported. Parent field is related to child
field through an existing field association: ([PATH: Field A;Field
B.”
5.4.3.50
Field type cannot be
changed
During
the import of field associations, if a field has been configured as either
a parent or child and field association data exists for that field, return
the following error message: “The field type for [Field name] cannot be
changed because it is used in a field
association.”
5.4.3.51
Export name required
On the
Launch Export window, if the Launch button is clicked and an export name
has not been provided for a field association export, return the following
error message: “You must enter a value for
name.”
5.4.3.52
Field selection required
On the
Launch Export window, if the Launch button is clicked and a selection has
not been made in the “Select field” control, return the following error
message: “You must select a field to be
exported.”
5.4.3.53
Field [or Option]
inactivation
Within
WorkBench, when taking the Inactivate or Delete action against a field or
option that is used within a field association, return a warning message
at the top of the screen (per existing WB functionality); “Before
deleting/inactivating this field [option] you should review the following
issues:” A grid will be
presented with a hyperlink labeled “Field Associations” in the left column
and the applicable associations listed in the right column. Format for the
right column = Child of [parent field name] or Parent of [child field
name]. Clicking on the Field
associations hyperlink will display the following message: “This field [option] is used in a
field association. If you inactivate/delete it, the associations listed
will be removed.”
| 